Track last SNTP sync time to flag a stale clock on the Services tile#1221
Draft
gskjold wants to merge 1 commit into
Draft
Track last SNTP sync time to flag a stale clock on the Services tile#1221gskjold wants to merge 1 commit into
gskjold wants to merge 1 commit into
Conversation
The NTP entry on the Services status tile only checked whether the system clock had ever been set (time() > BuildEpoch). A clock that was synced once and then silently stopped resyncing — which corrupts day-boundary energy accounting and shows up as a wrong GUI time — kept reporting green because the clock keeps ticking from millis(). Register a platform SNTP sync-notification callback that records millis64() at each successful sync: - ESP8266: settimeofday_cb(void(*)(bool from_sntp)) — the from_sntp flag lets us ignore the meter-timestamp settimeofday() so only real SNTP syncs count. - ESP32: sntp_set_time_sync_notification_cb(void(*)(struct timeval*)). The Services tile now reports NTP as degraded (yellow) when there has been no SNTP sync since boot or the last sync is older than 3h, and OK (green) only on a recent sync. Diagnostic only; no change to the accounting logic. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🔧 PR Build ArtifactsVersion: All environments built successfully. Download the zip files:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The NTP entry on the new Services status tile only checks whether the system clock has ever been set (
time() > BuildEpochinAmsWebServer.cpp). That misses the failure mode behind #1191: a clock that synced once and then silently stopped resyncing keeps ticking frommillis(), so the tile stays green even while the clock drifts and day-boundary energy accounting gets corrupted (and the GUI shows the wrong time).This adds a real freshness signal.
Changes
src/NtpStatus.{h,cpp}— registers a platform SNTP sync-notification callback that recordsmillis64()at each successful sync, exposed viantpLastSyncMillis():settimeofday_cb(void(*)(bool from_sntp))— thefrom_sntpflag lets us ignore the meter-timestampsettimeofday()atAmsToMqttBridge.cpp:1734, so only real SNTP syncs count.sntp_set_time_sync_notification_cb(void(*)(struct timeval*)).AmsToMqttBridge.cpp— register the callback once insetup().AmsWebServer.cpp— the Services tile NTP status is now yellow when there has been no SNTP sync since boot or the last sync is older than 3h (NTP_STALE_AFTER_SECONDS), and green only on a recent sync. Maps onto the existingbcol()colors; no UI changes needed.Diagnostic only — no change to the accounting logic.
Why draft
Investigating #1191. The reporter notes the GUI is exactly 1 hour off, which looks more like a DST/meter-timestamp-deviation issue than NTP drift. This PR is the diagnostic that will tell us whether NTP is actually still syncing on affected devices; root cause may turn out to be elsewhere (the meter-timestamp decode /
tzDST handling). Waiting on a data dump from the reporter before deciding whether more is needed here.Testing
pio run -e esp8266dev→ SUCCESS (confirmssettimeofday_cb(bool)overload)pio run -e esp32dev→ SUCCESS (confirmsesp_sntp.h/sntp_set_time_sync_notification_cb)Related: #1191
🤖 Generated with Claude Code